A flaw was found in 389 Directory Server. The CleanAllRUV and Abort CleanAllRUV replication-maintenance extended operations perform no authorization check, allowing an unauthenticated remote attacker to invoke them when nsslapd-allow-anonymous-access is enabled (the default), or any authenticated low-privilege user to invoke them otherwise. This allows removal of a replica ID from replication metadata, purging of changelog records, and interruption of administrator-initiated cleanup, which can leave replication inconsistent or unavailable.

A flaw was found in 389 Directory Server (389-ds-base). In idssaslcheckbind(), on a successful SASLOK from the underlying Cyrus SASL library, the connection is marked SASL-complete and bind credentials are installed via bindcredentialssetnolock() before the account-lock check (slapicheckaccountlock()) is performed for non-root binds. If the subsequent lock check determines the account is locked (nsAccountLock: true), the bind is failed and reported to the client, but the already-installed SASL-complete flag and bind credentials are not reverted. A client that already knows the correct password for an account that has since been administratively locked can bind via SASL PLAIN, receive an "account locked" failure response, and continue using the same, already-authenticated TCP connection to perform further LDAP operations as that account -- defeating account lock as an access-revocation control. Setting nsslapd-close-on-failed-bind does not mitigate this. This finding was independently reported by two unrelated parties (OpenAI Security Research and Andrew Rukin of Arenadata) who converged on the identical root cause.

A flaw was found in 389 Directory Server (389-ds-base). The getruvelementfromberval() function in ldap/servers/plugins/replication/repl5ruv.c copies digit characters from a network-supplied RUV berval into a fixed 16-byte stack buffer (ridbuff[RIDSTRSIZE]) without bounds checking the loop counter. A remote unauthenticated attacker can crash the ns-slapd process by sending a crafted StartNSDS50ReplicationRequest LDAP extended operation (OID 2.16.840.1.113730.3.5.12) containing more than 16 consecutive digit characters in the replica ID field. The overflow occurs during payload decoding in decodestartreplextop(), before the replicaisupdatedn() authorization check runs, making it exploitable without credentials on default configurations where anonymous access is enabled. On production builds with stack protectors, the impact is limited to denial of service (process abort). The vulnerable code path is: decodestartreplextop() -> decoderuv() -> ruvinitfrombervals() -> getruvelementfromberval().

A flaw was found in 389 Directory Server. The PBKDF2-SHA256 password verification function pbkdf2sha256pwcmp() in ldap/servers/plugins/pwdstorage/pbkdf2pwd.c uses standard memcmp() for hash comparison instead of the project's constant-time slapictmemcmp(). Every other password storage scheme in the same plugin uses slapictmemcmp(), which was introduced specifically to prevent timing side-channels (see CVE-2016-5405). This inconsistency allows a remote attacker with network access to the LDAP service to potentially infer partial hash information through repeated timing measurements of LDAP bind attempts. Practical exploitation is extremely difficult due to the PBKDF2 work factor (8192+ iterations, ~2ms computation time) which dominates and masks the nanosecond-level memcmp timing delta.

A heap-buffer-overflow flaw was found in 389 Directory Server (389-ds-base). When normalizing a Distinguished Name (DN) that contains a legacy-quoted value encoding a multivalued nested Relative Distinguished Name (RDN), the server can write past the end of a heap allocation while sorting RDN attribute-value pairs. An unauthenticated remote attacker can trigger this condition by sending an LDAP operation whose DN reaches the DN normalization routine, such as a search with a crafted base DN. This can corrupt heap memory and may cause denial of service.

Valid heap-buffer-overflow in slapidnnormalizeext() -> sortrdnavs() -> rdnavswap() (ldap/servers/slapd/dn.c). Triggered when a DN contains a legacy-quoted value encoding a multivalued nested RDN. On closing quote, nested attribute-value tracking is not finalized; a subsequent separator can leave stale pointers that produce overlapping berval entries. In-place sorting then writes past the heap allocation in rdnavswap(). Reachable pre-auth via any LDAP operation whose DN is normalized (search base DN confirmed). Reproduced on RHEL 9.8 (389-ds-base-2.8.0-7.el98) with reporter PoC. Production behavior (no ASAN/MALLOCCHECK): malformed DN often returns err=34 (Invalid DN syntax); server continues. With MALLOCCHECK=3: general protection fault in libc, ns-slapd terminates.

389-ds-base security assessment finding 021 (2026-04-22).

Pre-auth LDAP filter injection in CleanAllRUV status-check extop (OID 2.16.840.1.113730.3.6.8). Handler multisupplierextopcleanruvcheckstatus() in replextop.c passes attacker-supplied filter unsanitized to internal cn=config search with replication plugin identity. No auth checks (unlike other replication extops).

With default nsslapd-allow-anonymous-access: on, anonymous bind suffices. Boolean oracle extracts 31 cn=config attributes (replication bind DN, password storage scheme, paths, ACI keywords). Password hashes not extractable via substring.

PoC confirmed: RHEL 7 (389-ds-base-1.3.11.1-5.el79), Fedora 42 (389-ds-base-3.1.4-6.fc42).

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5). Red Hat impact: Moderate. CWE-90, CWE-306, CWE-20.

mishandling of the filter that would yield incorrect results, but as that has progressed, we have determined that it actually is an access control bypass. This may allow any remote un-authenticated user to issue a filter that allows searching for database items they do not have access to, including but not limited to potentially userPassword hashes and other sensitive data.

https://github.com/389ds/389-ds-base/issues/5170